Packet communications have evolved to a point where voice sessions, or calls, can be supported with essentially the same quality of service as that provided by circuit-switched communications. Packet communications are generally supported over packet subsystems, which were initially supported by local area networks, but are now supported by wireless local area networks (WLANs). Using WLAN access, user elements can support voice sessions using packet communications while moving throughout the WLAN. As such, WLAN access provides users the same freedom of movement within a WLAN as cellular access provides users within a cellular environment.
In many instances, the coverage areas provided by WLANs and cellular networks are complementary. For example, a WLAN may be established within a building complex in which cellular coverage is limited. Given the localized nature of WLAN coverage, cellular networks could bridge the coverage gaps between WLANs. Unfortunately, WLAN access technology is independent of cellular access technology. Cellular networks generally support circuit-switched communications, and WLANs support packet communications. As such, user elements have been developed to support both cellular and WLAN communications using different communication interfaces. With these user elements, users can initiate and receive calls via the cellular network and WLAN using the respective communication interfaces.
In co-pending U.S. patent application Ser. No. 11/378,776, filed Mar. 17, 2006, and entitled CIRCUIT-SWITCHED AND MULTIMEDIA SUBSYSTEM VOICE CONTINUITY, which is incorporated herein by reference, applicant has proposed moving a user element's service control, including call control, from a cellular network to a multimedia subsystem (MS), such as the Internet Protocol (IP) Multimedia Subsystem (IMS). As such, call control is provided by the MS irrespective of whether the user element is using cellular or WLAN access for the call. For clarity and conciseness, a cellular network providing circuit-switched communications is referred to as circuit-switched subsystem (CS), and a WLAN providing packet communications is assumed to be part of or associated with the MS. In general, wireless communication techniques having relatively limited range, such as WLAN techniques, are referred to as local wireless communication techniques. Thus, local wireless communication techniques support packet-based communications, wherein cellular communication techniques will generally support circuit-switched communications. Further, the wireless access for local wireless techniques are of a limited range with respect to cellular access techniques.
Call control for originating and terminating calls in the CS or MS as well as transferring calls between the CS and MS is anchored at a continuity control function (CCF) in the MS. All call signaling for the call is passed through the CCF. The CCF is a service provided in the user element's home MS and anchors the user element's active CS calls and MS sessions to enable mobility across the CS and MS while maintaining CS calls or MS sessions.
For CS calls, the CCF operates to anchor the bearer path for calls originated or terminated through the CS by the user element at a media gateway, which is controlled by a media gateway controller of the home MS. The CCF employs Third Party Call Control function to provide call control in the CS. For MS calls, the CCF provides call control by interacting with the user element and a remote endpoint to establish a bearer path directly between the user element and the remote endpoint through the MS. The CCF is addressable using public service identities (PSI). In the CS, a directory number associated with the CCF is used for routing call signaling messages within the CS. In the MS, a uniform resource location (URL) associated with the CCF is used for routing call signaling messages within the MS. In the following description, 3GPP TS 24H.008 (DTAP) is used in the CS, while the Session Initiation Protocol (SIP) is used in the MS to effect origination, termination, and transfer of calls. Those skilled in the art will recognize other applicable and useful protocols as substitutes for DTAP and SIP.
Turning now to FIG. 1, a communication environment 10 is illustrated where a home MS 12H and a visited CS 14 support communications for a user element 16. The user element 16 includes a CS client 18 and an MS client 20, which are configured to support circuit-switched communications via the visited CS 14 as well as packet communications via the home MS 12H, respectively. For communications within the visited CS 14, a visited mobile switching center (VMSC) 22 will support circuit-switched communications for the user element 16. The VMSC 22 may interact with the home MS 12H via a media gateway controller (MGC) 24H and an associated media gateway (MG) 26H, both of which are affiliated with the MS 12H.
The home MS 12H may include various functions or entities, including an interrogating and serving call/session control function (I/S-CSCF) 28, a CCF 30, an application server (AS) 32, and a home subscriber service (HSS) 34. Notably, the interrogating CSCF provides the standard I-CSCF functions and the serving CSCF provides standard S-CSCF functions. These functions are represented in the I/S-CSCF 28 for conciseness. Further, the HSS 34 may have a presence in both the visited CS 14 and the home MS 12H. The HSS 34 may include a home location resource component for home CS. Call/session control functions (CSCFs) in the home MS 12H generally act as SIP proxies and provide various functions in association with call control, as will be appreciated by those skilled in the art. In operation, an interrogating CSCF (I-CSCF) may interact with the HSS 34 to identify the serving CSCF (S-CSCF), which will be assigned to support a given user element. The HSS 34 may maintain an association between a user element 16 and a particular CCF 30 that is assigned to the user element 16. As such, the HSS 34 will assist in identifying a serving CSCF for the user element 16, as well as keep an association between a particular CCF 30 and the user element 16. The CCF PSI for the user element 16 may be provisioned in the user element 16 to enable the user element 16 to initiate transfers and the like controlled by the CCF 30. Alternatively, the CCF PSI may be transferred to the user element 16 upon network registration.
Depending on whether the user element 16 is registered in the home MS 12H, different techniques may be used to access the home MS 12H. When the user element 16 is registered in the home MS 12H, the user element 16 will have an S-CSCF assigned to it, and will use that S-CSCF to access the CCF 30. When the user element 16 is not registered in the home MS 12H, a temporary S-CSCF may be assigned to the user element 16, and the temporary S-CSCF will be used to access the CCF 30.
The application servers 32 may be invoked and placed within the call signaling path to implement any number of features or services. When a particular application service provided by an application server 32 is invoked, all signaling for the associated call or session is passed through the application service, which has the opportunity to process call signaling messages as necessary to implement the desired service. Notably, the CCF 30 acts like a service, and as such, the I/S-CSCF 28 will operate to pass all call signaling messages for the call through the CCF 30, thereby allowing the CCF 30 to act as an anchor for the call.
In FIG. 1, the user element 16 is engaged in a call supported by the CS client 18 and controlled by the CCF 30. As such, call signaling for the call passes through the VMSC 22, media gateway controller 24H, I/S-CSCF 28, CCF 30, and perhaps application server 32, if a service is invoked, on its way toward a remote endpoint 36. Notably, the access signaling leg, which is provided by the visited CS 14, is anchored at the CCF 30 and extends through the I/S-CSCF 28, media gateway controller 24H, the VMSC 22, and CS client 18 of the user element 16. The remote signaling leg toward the remote endpoint 36 is anchored in the CCF 30 and extends through the I/S-CSCF 28 and the application server 32. In this configuration, the CCF 30 can maintain control of the call and provide any necessary call processing during the call. Further, if a call transfer is required, the CCF 30 maintains the remote signaling leg and establishes a new access signaling leg.
The bearer path for the call illustrated in FIG. 1 extends from the CS client 18 through the VMSC 22 and media gateway 26H on its way toward the remote endpoint 36. Notably, the media gateway controller 24H cooperates with the media gateway 26H, such that a circuit-switched connection may be established between the media gateway 26H and the CS client 18 via the VMSC 22. The packet session may be established for the call from the media gateway 26H through the home MS 12H toward the remote endpoint 36.
With reference to FIG. 2, a call supported by the MS client 20 of the user element 16 is represented. Notably, the call does not extend through the visited CS 14, and will not employ the services of the VMSC 22, media gateway controller 24H, or media gateway 26H. Instead, the MS client 20 will support call signaling directly with the home MS 12H, and in particular with the CCF 30 via a serving-CSCF (S-CSCF) 40. Notably, the I/S-CSCF 28 and the S-CSCF 40 may represent the same CSCF or different CSCFs, depending on how the user element 16 registers with the home MS 12H.
As illustrated, call signaling is anchored in the CCF 30, wherein an access signaling leg is provided between the CCF 30 and the MS client 20 via the S-CSCF 40. A remote signaling leg is supported between the remote endpoint 36 and the CCF 30 via the S-CSCF 40 and any desired application servers 32 that may provide additional services in association with the call. The bearer path will extend from the MS client 20 toward the remote endpoint 36 via the home MS 12H, without traveling through the visited CS 14 (FIG. 1). Again, the CCF 30 anchors the call, such that if transfer is required, the remote signaling leg toward the remote endpoint 36 can be maintained, while the access signaling leg may be changed to facilitate the transfer from the home MS 12H to the visited CS 14. For transfer of calls between the visited CS 14 and the home MS 12H, the access signaling legs illustrated in FIGS. 1 and 2 will be changed to support the transfer, while the remote signaling leg is maintained by the CCF 30.
When the user element 16 is originating a call, the CCF 30 appears as a service provided by an application server, such as the application server 32. The CCF 30 may be invoked as the first service in a chain of services. When the user element 16 is terminating a call, the CCF 30 is invoked as the last service in a chain of services. By locating the CCF 30 with respect to the other services in this manner, other applications associated with the call are anchored by the CCF 30 as part of the remote signaling leg of the call, and are therefore not impacted by transfers affecting the access signaling leg.
The MSISDN or other user element identifier is owned and controlled by the home MS 12H to enable anchoring of incoming calls intended for the user element 16 at the CCF 30. Incoming calls destined for the user element 16 and originated from the visited CS 14, the public switched telephone network (PSTN), or other MS can be anchored at the CCF 30 by setting up routing functions at the originating service nodes, such that incoming calls intended for the user element 16 are delivered to the home MS 12H. As such, the CCF 30 can take the necessary steps to find the user element 16 and route the call to the user element 16, even if the user element 16 is in the visited CS 14 when the call arrives.
As indicated, the HSS 34 may store filter criteria associated with the CCF 30 as part of the user element's subscription profile. The CCF filter criteria is downloaded to the currently assigned S-CSCF (28 or 40) as part of the initial filter criteria to use when the user element 16 registers with the home MS 12H. This filter criteria is generally executed at the S-CSCF 40 (or 28) upon initiation of a call or session from the user element 16 or upon receipt of an incoming session intended for the user element 16. These filter criteria will instruct the S-CSCF 40 (or 28) to invoke the CCF 30 to control at least the bearer path for the call or session.
As illustrated in FIG. 1, when the user element 16 is being served by the visited CS 14, which is located a relatively long distance from the home MS 12H, routing the bearer path to the media gateway 26H in the home MS 12H may induce some backhaul inefficiencies. As such, the bearer path may be indirectly routed between the user element 16 and the remote endpoint 36 through the media gateway 26H instead of being more directly routed through the visited CS 14 and more local networks.
Accordingly, there is a need for a technique to effectively support calls for the user element 16 over both the visited CS 14 and the home MS 12 at the CCF 30. In conjunction, there is a further need to construct a more efficient bearer path between the user element 16 and the remote endpoint 36 when the visited CS 14 is located a relatively long distance from the home MS 12H.